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DETAILED ACTION 

1 . Claims 1-30 are presented for examination. 

Information Disclosure Statement 

2. The information disclosure statement (IDS) submitted on October 14, 2003. The 
submission is in compliance with the provisions of 37 CFR 1 .97. Accordingly, the 
information disclosure statement is being considered by the examiner. 

Claim Rejections - 35 USC §112 

3. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

4. Claims 2, 4, 7, 10, 12, 18, 20, 25, 26, and 28-30 are rejected under 35 

U.S.C. 1 12, second paragraph, as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. 

Claim 2 recites the limitation "the temporary contacts" in line 5. There is 
insufficient antecedent basis for this limitation in the claim. 

Claim 4 recites the limitation "the query" in lines 2-3,and 5. There is insufficient 
antecedent basis for this limitation in the claim. Claim 4 depends on claim 1 , and no 
query is defined in claim 1. 
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Claim 7 recites the limitation "the date" in line 4. There is insufficient antecedent 
basis for this limitation in the claim. 

Claim 10 recites the limitation "the temporary contacts" in lines 5-6. There is 
insufficient antecedent basis for this limitation in the claim. 

Claim 12 recites the limitation "the query" in lines 3 and 5. There is insufficient 
antecedent basis for this limitation in the claim. Claim 4 depends on claim 9, and no 
query is defined in claim 9. 

Claim 18 recites the limitation "the temporary contacts" in lines 5-6. There is 
insufficient antecedent basis for this limitation in the claim. 

Claim 20 recites the limitation "the query" in lines 3 and 5. There is insufficient 
antecedent basis for this limitation in the claim. Claim 20 depends on claim 17, and no 
query is defined in claim 17. 

Claim 25 recites the limitation "the temporary contacts" in line 1 1 . There is 
insufficient antecedent basis for this limitation in the claim. 

Claim 26 recites the limitations "the date" in line 10, and "the participant 
information" in lines 16-17. There are insufficient antecedent basis for those limitations 
in the claim. 

Claim 28 recites the limitation "the date" in line 15. There is insufficient 
antecedent basis for this limitation in the claim. 

Claim 29 recites the limitation "the temporary contacts" in lines 12-13. There is 
insufficient antecedent basis for this limitation in the claim. 
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Claim 30 recites the limitations "the date" in line 12, and "the participant 
information" In lines 18-19. There are insufficient antecedent basis for those limitations 
in the claim. 



Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

6. Claims 1 , 9, and 1 7 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Knauerhase et al. (hereinafter, Knauerhase), U.S. Pub. No. 2004/0203746 A1 . 



Regarding claim 1 , Knauerhase teaches a computer-implemented method of 
managing instant messenger lists (i.e., adding/removing contacts from buddy list, page 
2 paragraphs [0026]-[0028]), said method comprising: 

receiving, from one or more computerized sources (i.e., server 115, Fig. 1), 
contact data corresponding to a plurality of contacts (i.e., mobile client device 415 
receives contact in fonvation, Fig. 1, page 3 paragraphs [0033]-[0037]); 



Application/Control Number: 10/684,986 Page 5 

Art Unit: 2155 

adding the received contact data to a buddy list associated with a user's instant 
messaging computer application (i.e., adding the partner/contacts to the buddy list of 
the client, page 2 paragraph [0026]); 

selecting one of the contacts added to the user's buddy list (i.e., the user may 
choose/select which persons/contacts on the buddy list the user wishes to be informed 
about page 3 paragraph [0038] and page 4 paragraph [0040]); and 

establishing an instant messaging session with the selected contact {Knauerhase 
discloses if the mobile device has a buddy list associated with it, the user may choose 
which persons on the buddy list the user wishes to be informed about, and 
communicate with those persons, page 3 paragraph [0038] and page 4 paragraph 
[0040]. In order to communicate with the selected person/contact on the buddy list, an 
instant messaging session with the selected person/contact must be established). 

Regarding claim 9, Knauerhase teaches information handling system (i.e., 
mobile client device 700, Fig. 7) comprising: 

one or more processors {i.e., processor 710, Fig. 7); 

a memory (i.e., RAM or a main memory 715, Fig. 7) accessible by the processors 
(i.e., RAM or a main memory 715 for storing information and instructions to be executed 
by processor 710, page 4 paragraph [0043])\ 

a network interface (i.e., communication device 750, Fig. 7) connecting the 
information handling system to a computer network (i.e., the mobile device 700 may be 
linked to a network using communication device 750, page 4 paragraph [0045])\ 



Application/Control Number: 10/684,986 Page 6 

Art Unit: 2155 

a software tool for managing instant messenger lists, the software tool including 
software (i.e., instructions, page 4 paragraph [0044]) effective to: 

receiving, from one or more computerized sources (i.e., server 115, Fig. 1), 
contact data corresponding to a plurality of contacts (i.e., mobile client device 415 
receives contact information, Fig. 1, page 3 paragraphs [0033H0037])\ 

adding the received contact data to a buddy list associated with a user's instant 
messaging computer application (i.e., adding the partner/contacts to the buddy list of 
the client, page 2 paragraph [0026]); 

selecting one of the contacts added to the user's buddy list (i.e., the user may 
choose/select which persons/contacts on the buddy list the user wishes to be informed 
about, page 3 paragraph [0038] and page 4 paragraph [0040]); and 

establishing an instant messaging session with the selected contact {Knauerhase 
discloses if the mobile device has a buddy list associated with it, the user may choose 
which persons on the buddy list the user wishes to be informed about, and 
communicate with those persons, page 3 paragraph [0038] and page 4 paragraph 
[0040]. In order to communicate with the selected person/contact on the buddy list, an 
instant messaging session with the selected person/contact must be established). 

Regarding claim 17, this claim is a computer program product stored on a 
computer operable media for managing instant messenger lists, said computer program 
product comprising software effective to perform the method of claim 1 , discussed 
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above, same rationale of rejection is applicable. 

Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

8. Claims 2. 4, 10. 12. 18, 20, 25, 27. and 29 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Knauerhase et al. (hereinafter, Knauerhase), U.S. Pub. No. 
2004/0203746 Al, in view of Malik, U.S. Pub. No. 2003/0220976 A1. 

Regarding claim 2, Knauerhase teaches the method as described in claim 1. 

Knauerhase does not explicitly teach indicating that one or more of the contacts 
added to the user's buddy list is a temporary contact; storing an expiration date 
corresponding to each of the temporary contacts; periodically comparing a current date 
to the expiration dates stored for the temporary contacts; and removing the contact data 
corresponding to the temporary contacts in response to the comparison. 

Malik teaches indicating that one or more of the contacts added to the user's 
buddy list is a temporary contact (i.e., request to add a temporary contact to the client 
resource list, page 5 paragraph [0046]); storing an expiration date corresponding to 
each of the temporary contacts (i.e., the user can enter the expiration/time 335 for the 
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temporary resource list After entering the temporary contact unique identification and 
expiration, the universal server 130 will add the temporary contact 300 to the database 
system 250\ Fig. 5 paragraph [0046]); periodically comparing a current date to the 
expiration dates stored for the temporary contacts (i.e., at regular intervals, check the 
expiration periods 335, 340 of the temporary group 10 to ensure that no temporary 
contacts 300, 320 have expired, page 4 paragraph [0042], and page 5 paragraph 
[0045]); and removing the contact data corresponding to the temporary contacts in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 5 paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to designate the contact as 
a temporary contact by storing expiration date corresponding to each of contacts, and to 
remove the contact after expiration date as taught by Malik. One would be motivated to 
do so to allow the client to control how long a contact is stored in the client's buddy list 
without requiring the user to actively monitor and remove old contacts (Malik, page 4 
paragraph [0039] lines 14-17). 

Regarding claim 4, Knauerhase teaches the method as described in claim 1. 

Knauerhase does not explicitly teach receiving an expiration date corresponding 
to the query; storing the expiration date with the contact data received as a result of the 
query; periodically comparing a current date to the expiration date; and removing the 
contact data in response to the comparison. 
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Malik teaches receiving an expiration date corresponding to a query (i.e., prompt 
the client for expiration data for temporary contact to be stored in the resource list, 
when expiration date is received, the temporary contact is recorded into the database 
system along with expiration date, Fig. 4 page 5 paragraph [0045]); 

storing the expiration date with the contact data received as a result of the query 
(i.e., the temporary contact is recorded/stored into the database system 250' along with 
expiration date 335, Fig. 4 page 5 paragraph [0045]); 

periodically comparing a current date to the expiration date (i.e., check for 
expiration at a regular intervals, page 5 paragraph [0045]); and 

removing the contact data in response to the comparison (i.e., if the temporary 
contact is expired, the temporary contact is removed from the resource list, page 5 
paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to combine the teachings of Knauerhase to include the steps of 
receiving an expiration date corresponding to the query, storing the expiration date with 
the contact data received as a result of the query, periodically comparing a current date 
to the expiration date, and removing the contact data in response to the comparison as 
taught by Malik. One would be motivated to do so to enable the contact(s) to be 
automatically deleted after the expiration date, thereby allowing the client to control how 
long a contact is stored in the client's buddy list without requiring the user to actively 
monitor and remove old contacts (Malik, page 4 paragraph [0039] lines 14-17). 
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Regarding claim 10, Knauerhase teaches the method as described in claim 9. 

Knauerhase does not explicitly teach indicating that one or more of the contacts 
added to the user's buddy list is a temporary contact; storing an expiration date 
corresponding to each of the temporary contacts; periodically comparing a current date 
to the expiration dates stored for the temporary contacts; and removing the contact data 
corresponding to the temporary contacts in response to the comparison. 

Malik teaches indicating that one or more of the contacts added to the user's 
buddy list is a temporary contact (i.e., request to add a temporary contact to the client 
resource list, page 5 paragraph [0046]); storing an expiration date corresponding to 
each of the temporary contacts (i.e., the user can enter the expirationAime 335 for the 
temporary resource list After entering the temporary contact unique identification and 
expiration, the universal server 130 will add the temporary contact 300 to the database 
system 250\ Fig. 5 paragraph [0046]); periodically comparing a current date to the 
expiration dates stored for the temporary contacts (i.e., at regular intervals, check the 
expiration periods 335, 340 of the temporary group 10 to ensure that no temporary 
contacts 300, 320 have expired, page 4 paragraph [0042], and page 5 paragraph 
[0045]); and removing the contact data corresponding to the temporary contacts in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 5 paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to designate the contact as 
a temporary contact by storing expiration date corresponding to each of contacts, and to 
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remove the contact after expiration date as taught by Malik. One would be motivated to 
do so to allow the client to control how long a contact is stored in the client's buddy list 
without requiring the user to actively monitor and remove old contacts (Malik, page 4 
paragraph [0039] lines 14-17). 

Regarding claim 12, Knauerhase teaches the method as described in claim 9. 

Knauerhase does not explicitly teach receiving an expiration date corresponding 
to the query; storing the expiration date with the contact data received as a result of the 
query; periodically comparing a current date to the expiration date; and removing the 
contact data in response to the comparison. 

Malik teaches receiving an expiration date corresponding to a query (i.e., prompt 
the client for expiration data for temporary contact to be stored in the resource list, 
when expiration date is received, the temporary contact is recorded into the database 
system along with expiration date, Fig. 4 page 5 paragraph [0045]); 

storing the expiration date with the contact data received as a result of the query 
(i.e., the temporary contact is recorded/stored into the database system 250' along with 
expiration date 335, Fig. 4 page 5 paragraph [0045]); 

periodically comparing a current date to the expiration date (i.e., check for 
expiration at a regular intervals, page 5 paragraph [0045]); and 

removing the contact data in response to the comparison (i.e., if the temporary 
contact is expired, the temporary contact is removed from the resource list, page 5 
paragraph [0045]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to combine the teachings of Knauerhase to include the steps of 
receiving an expiration date corresponding to the query, storing the expiration date with 
the contact data received as a result of the query, periodically comparing a current date 
to the expiration date, and removing the contact data in response to the comparison as 
taught by Malik. One would be motivated to do so to enable the contact(s) to be 
automatically deleted after the expiration date, thereby allowing the client to control how 
long a contact is stored in the client's buddy list without requiring the user to actively 
monitor and remove old contacts (Malik, page 4 paragraph [0039] lines 14-17). 

Regarding claim 18, this claim comprises the computer program corresponding 
to the method claim 2, same rationale of rejection is applicable. 

Regarding claim 20, this claim comprises the computer program product 
corresponding to the method claim 4, same rationale of rejection is applicable. 

Regarding claim 25, Knauerhase teaches a computer-implemented method of 
managing instant messenger lists (i.e., adding/removing contacts from buddy list, page 
2 paragraphs [0026]-[00281), said method comprising: 

receiving, from one or more computerized sources (i.e., server 115, Fig. 1), 
contact data corresponding to a plurality of contacts (i.e., mobile client device 415 
receives contact information, Fig. 1, page 3 paragraphs [0033]-[0037]); 
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adding the received contact data to a buddy list associated with a user's instant 
messaging computer application (i.e., adding the partner/contacts to the buddy list of 
the client, page 2 paragraph [0026]); 

Knauerhase does not explicitly teach indicating that one or more of the contacts 
added to the user's buddy list is a temporary contact; storing an expiration date 
corresponding to each of the temporary contacts; periodically comparing a current date 
to the expiration dates stored for the temporary contacts; and removing the contact data 
corresponding to the temporary contacts in response to the comparison. 

Malik teaches a system wherein temporary contact aliases are provided (see 
abstract). Malik teaches indicating that one or more of the contacts added to the user's 
buddy list is a temporary contact (i.e., request to add a temporary contact to the client 
resource list, page 5 paragraph [0046]); storing an expiration date corresponding to 
each of the temporary contacts (i.e., the user can enter the expiration/time 335 for the 
temporary resource list. After entering the temporary contact unique identification and 
expiration, the universal sen/er 130 will add the temporary contact 300 to the database 
system 250\ Fig. 5 paragraph [0046]); periodically comparing a current dafe to the 
expiration dates stored for the temporary contacts (i.e., at regular intervals, check the 
expiration periods 335, 340 of the temporary group 10 to ensure that no temporary 
contacts 300, 320 have expired, page 4 paragraph [0042], and page 5 paragraph 
[0045])\ and removing the contact data corresponding to the temporary contacts in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 5 paragraph [0045]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to designate the contact as 
a temporary contact by storing expiration date corresponding to each of contacts, and to 
remove the contact after expiration date as taught by Malik. One would be motivated to 
do so to allow the client to control how long a contact is stored in the client's buddy list 
without requiring the user to actively monitor and remove old contacts (Malik, page 4 
paragraph [0039] lines 14-17). 

Regarding claim 27, Knauerhase teaches information handling system (i.e., 
mobile client device 700, Fig. 7) comprising: 

one or more processors {i.e., processor 710, Fig. 7); 

a memory (i.e., RAM or a main memory 715, Fig. 7) accessible by the processors 
(i.e., RAM or a main memory 715 for storing information and instructions to be executed 
by processor 710, page 4 paragraph [0043])\ 

a network interface (i.e., communication device 750, Fig. 7) connecting the 
information handling system to a computer network (i.e., the mobile device 700 maybe 
linked to a network using communication device 750, page 4 paragraph [0045])\ 

a software tool for managing instant messenger lists, the software tool including 
software (i.e., instructions, page 4 paragraph [0044]) effective to: 

receiving, from one or more computerized sources (i.e., server 115, Fig. 1), 
contact data corresponding to a plurality of contacts (i.e., mobile client device 415 
receives contact information. Fig. 1, page 3 paragraphs [0033]-[0037]); 
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adding the received contact data to a buddy list associated with a user's instant 
messaging computer application (i.e., adding the partner/contacts to the buddy list of 
the client, page 2 paragraph [0026]); 

Knauerhase does not explicitly teach indicating that one or more of the contacts 
added to the user's buddy list is a temporary contact; storing an expiration date 
corresponding to each of the temporary contacts; periodically comparing a current date 
to the expiration dates stored for the temporary contacts; and removing the contact data 
corresponding to the temporary contacts in response to the comparison. 

Malik teaches a system wherein temporary contact aliases are provided (see 
abstract). Malik teaches indicating that one or more of the contacts added to the user's 
buddy list is a temporary contact (i.e., request to add a temporary contact to the client 
resource list, page 5 paragraph [0046]); storing an expiration date corresponding to 
each of the temporary contacts (i.e., the user can enter the expirationAime 335 for the 
temporary resource list. After entering the temporary contact unique identification and 
expiration, the universal sen/er 130 will add the temporary contact 300 to the database 
system 250\ Fig. 5 paragraph [0046]); periodically comparing a current date to the 
expiration dates stored for the temporary contacts (i.e., at regular intervals, check the 
expiration periods 335, 340 of the temporary group 10 to ensure that no temporary 
contacts 300, 320 have expired, page 4 paragraph [0042], and page 5 paragraph 
[0045])', and removing the contact data corresponding to the temporary contacts in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 5 paragraph [0045]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to designate the contact as 
a temporary contact by storing expiration date corresponding to each of contacts, and to 
remove the contact after expiration date as taught by Malik. One would be motivated to 
do so to allow the client to control how long a contact is stored in the client's buddy list 
without requiring the user to actively monitor and remove old contacts (Malik, page 4 
paragraph [0039] lines 14-17). 

Regarding claim 29, this claim comprises a computer program product stored on 
a computer operable media for performing a corresponding method claim 25, discussed 
above, same rationale of rejection is applicable. 

9. Claims 3, 5, 6, 11, 13, 14, 19, 21, and 22 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Knauerhase et al. (hereinafter, Knauerhase), U.S. Pub. No. 
2004/0203746 Al, in view of Keskar et al. (hereinafter, Keskar), U.S. Patent No. 
6,785,681 B1. 

Regarding claim 3, Knauerhase teaches the method as described in claim 1 . 

Knauerhase does not explicitly teach prior to the reception of the contact data: 
constructing a query of contact information requested by the user; and performing the 
query at a database, wherein the database stores the contact information that includes 
the contact data corresponding to the contacts; and wherein the contact data received is 
a result of the performed query. 
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Keskar teaches technique for generating a list of people relevant to a task (see 
abstract). Keskar teaches teach prior to the reception of the contact data: constructing 
a query of contact information requested by the user (i.e., create a query for 
persons/contacts who may be interested in the content, col. 1 lines 40-50); and 
perfomning the query at a database (i.e., query is directed to the tracking database 22, 
col. 1 lines 51-59), wherein the database stores the contact infonnation that includes the 
contact data corresponding to the contacts (i.e., the tracking database includes user 
table 60, Fig. 3); and wherein the contact data received Is a result of the perfomned 
query (I.e., the results of the search can Include a list of people/contacts presented to 
the user, col. 1 lines 57-60). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to query database for the 
contact infonnation prior to the reception of the contact infonnation as taught by 
Keskar. One would be motivated to do so to improve the task efficiency by 
automatically providing/adding a list of people/contacts to a buddy list (Keskar, col. 5 
lines 45-55). 

Regarding claim 5, Knauerhase teaches the method as described in claim 1 . 

Knauerhase does not explicitly teach prior to the reception of the contact data: 
selecting one or more calendar entries from an electronic calendar corresponding to the 
user; and retrieving, from the selected calendar entries, calendar data that includes 
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participant information for participants of the selected calendar entries; and wherein the 
contact data received includes the participant information. 

Keskar teaches prior to the reception of the contact data: selecting one or more 
calendar entries from an electronic calendar corresponding to the user (i.e., a criteria 
can be applied to the list of people before the list is presented to the client. The criteria, 
currently scheduled meetings for the sender, can help refine/select the name of persons 
in the list, col. 5 lines 30-55); and retrieving, from the selected calendar entries, 
calendar data that includes participant information for participants of the selected 
calendar entries (i.e., provide a list of people that are relevant to the task, col. 5 lines 
45-55); and wherein the contact data received includes the participant information (i.e., 
meeting attendees can be added to the list of people as the meeting agenda. In instant 
messaging scenario, the list of people can be added to a buddy list, col. 5 lines 45-63). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to combine the teachings of Knauerhase to include the step of 
retrieving calendar data as taught by Keskar. One would be motivated to do so to would 
be motivated to do so to improve the task efficiency by automatically providing/adding a 
list of people/contacts to a buddy list without searching through a large address book 
(Keskar, col. 5 lines 45-55). 

Regarding claim 6, Knauerhase teaches the method as described in claim 1 . 
Knauerhase does not teach creating a buddy group within the user's buddy list. 
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wherein the created buddy group corresponds to a selected calendar entry from 
an electronic calendar corresponding to the user; prior to the reception of the contact 
data: selecting the calendar entry from the user's electronic calendar; and retrieving, 
from the selected calendar entry, calendar data that includes participant information for 
participants of the selected calendar entry; and subsequent to the reception of the 
contact data: storing the received contact data in the buddy group, wherein the contact 
data received includes the participant information. 

Keskar teaches creating a buddy group within the user's buddy list (i.e., a list of 
people can be added to a buddy list, col. 5 lines 45-55), wherein the created buddy 
group corresponds to a selected calendar entry from an electronic calendar 
corresponding to the user (i.e., meeting attendees can be added to a list of people. If 
the meeting is to be held online, then participants are invited into an instant messaging 
chat room, coL 5 lines 45-63); prior to the reception of the contact data: selecting the 
calendar entry from the user's electronic calendar (i.e., a criteria can be applied to the 
list of people before the list is presented to the client. The criteria, currently scheduled 
meetings for the sender, can help refine/select the name of persons in the list, col. 5 
lines 30-55); and retrieving, from the selected calendar entry, calendar data that 
includes participant information for participants of the selected calendar entry (i.e., 
provide a list of people that are relevant to the task, col. 5 lines 45-55); and subsequent 
to the reception of the contact data: storing the received contact data in the buddy 
group, wherein the contact data received includes the participant information (i.e.. 
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meeting attendees can be added to the list of people as the meeting agenda. In instant 
messaging scenario, the list of people can be added to a buddy list, col. 5 lines 45-63). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to create a buddy group 
within the user's buddy list as taught by Keskar. One would be motivated to do so to 
would be motivated to do so to improve the task efficiency by automatically 
providing/adding a list of people/contacts of a current scheduled meeting for the user to 
the user's buddy list without searching through a large address book (Keskar. col. 5 
lines 45-55). 

Regarding claim 1 1 , Knauerhase teaches the method as described in claim 9. 

Knauerhase does not explicitly teach prior to the reception of the contact data: 
constructing a query of contact information requested by the user; and performing the 
query at a database, wherein the database stores the contact information that includes 
the contact data corresponding to the contacts; and wherein the contact data received is 
a result of the performed query. 

Keskar teaches technique for generating a list of people relevant to a task (see 
abstract). Keskar teaches teach prior to the reception of the contact data: constructing 
a query of contact information requested by the user (i.e., create a query for 
persons/contacts who may be interested in ttie content, coL 1 lines 40-50)] and 
performing the query at a database (i.e., query is directed to tlie tracl^ing database 22, 
col. 1 lines 51-59), wherein the database stores the contact information that includes the 
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cx)ntact data corresponding to the contacts (i.e., the tracking database includes user 
table 60, Fig. 3)] and wherein the contact data received is a result of the performed 
query (i.e., the results of the search can include a list of people/contacts presented to 
the user, col. 1 lines 57-60). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to query database for the 
contact information prior to the reception of the contact information as taught by 
Keskar. One would be motivated to do so to improve the task efficiency by 
automatically providing/adding a list of people/contacts to a buddy list (Keskar, col. 5 
lines 45-55). 

Regarding claim 13, Knauerhase teaches the method as described in claim 9. 

Knauerhase does not explicitly teach prior to the reception of the contact data: 
selecting one or more calendar entries from an electronic calendar corresponding to the 
user; and retrieving, from the selected calendar entries, calendar data that includes 
participant information for participants of the selected calendar entries; and wherein the 
contact data received includes the participant information. 

Keskar teaches prior to the reception of the contact data: selecting one or more 
calendar entries from an electronic calendar corresponding to the user (i.e., a criteria 
can be applied to the list of people before the list is presented to the client. The criteria, 
currently scheduled meetings for the sender, can help refine/select the name of persons 
in the list, col. 5 lines 30-55); and retrieving, from the selected calendar entries. 
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calendar data that includes participant information for participants of the selected 
calendar entries (i.e.. provide a list of people that are relevant to the task. col. 5 lines 
45-55); and wherein the contact data received includes the participant information (i.e., 
meeting attendees can be added to the list of people as the meeting agenda. In instant 
messaging scenario, the list of people can be added to a buddy list, col. 5 lines 45-63). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to combine the teachings of Knauerhase to include the step of 
retrieving calendar data as taught by Keskar. One would be motivated to do so to would 
be motivated to do so to improve the task efficiency by automatically providing/adding a 
list of people/contacts to a buddy list without searching through a large address book 
(Keskar, col. 5 lines 45-55). 

Regarding claim 14, Knauerhase teaches the method as described in claim 9. 
Knauerhase does not teach creating a buddy group within the user's buddy list, 
wherein the created buddy group corresponds to a selected calendar entry from 
an electronic calendar corresponding to the user; prior to the reception of the contact 
data: selecting the calendar entry from the user's electronic calendar; and retrieving, 
from the selected calendar entry, calendar data that includes participant information for 
participants of the selected calendar entry; and subsequent to the reception of the 
contact data: storing the received contact data in the buddy group, wherein the contact 
data received includes the participant information. 
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Keskar teaches creating a buddy group within the user's buddy list (i.e., a list of 
people can be added to a buddy list, coL 5 lines 45-55), wherein the created buddy 
group corresponds to a selected calendar entry from an electronic calendar 
corresponding to the user (i.e., meeting attendees can be added to a list of people. If 
the meeting is to be held online, then participants are invited into an instant messaging 
chat room, col. 5 lines 45-63); prior to the reception of the contact data: selecting the 
calendar entry from the user's electronic calendar (i.e., a criteria can be applied to the 
list of people before the list is presented to the client. The criteria, currently scheduled 
meetings for the sender, can help refine/select the name of persons in the list, col. 5 
lines 30-55); and retrieving, from the selected calendar entry, calendar data that 
includes participant information for participants of the selected calendar entry (i.e., 
provide a list of people that are relevant to the task, col. 5 lines 45-55); and subsequent 
to the reception of the contact data: storing the received contact data in the buddy 
group, wherein the contact data received includes the participant information (i.e., 
meeting attendees can be added to the list of people as the meeting agenda. In instant 
messaging scenario, the list of people can be added to a buddy list, col. 5 lines 45-63). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Knauerhase to create a buddy group 
within the user's buddy list as taught by Keskar. One would be motivated to do so to 
would be motivated to do so to improve the task efficiency by automatically 
providing/adding a list of people/contacts of a current scheduled meeting for the user to 
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the user's buddy list without searching through a large address book (Keskar, col. 5 
lines 45-55). 

Regarding claim 19, this claim comprises the computer program product 
corresponding to the method claim 3, same rationale of rejection is applicable. 

Regarding claim 21 , this claim comprises the computer program product 
con^esponding to the method claim 5, same rationale of rejection is applicable. 

Regarding claim 22, this claim comprises the computer program product 
corresponding to the method claim 6, same rationale of rejection is applicable. 

10. Claims 7, 15 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Knauerhase et al. (hereinafter, Knauerhase), U.S. Pub. No. 2004/0203746 A1, in 
view of Keskar et al. (hereinafter, Keskar), U.S. Patent No. 6,785,681 B1 , and further in 
view of Malik. U.S. Pub. No. 2003/0220976 Al . 

Regarding claim 7, Knauerhase teaches the method as described in claim 6. 

the combination of teachings of Knauerhase and Keskar does not explicitly 
teach storing an expiration date corresponding to the created buddy group, wherein the 
expiration date is derived from the date of the selected calendar entry; periodically 
comparing a current date to the expiration date stored for the buddy group; and 
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removing the buddy group, including the contact data added to the buddy group, in 
response to the comparison. 

Malik teaches storing an expiration date {expiration period 335, 340, Fig. 3) 
corresponding to the created buddy group {i.e., wtien expiration date 335 is received, 
ttie temporary contact 300 is recorded into database along with expiration 335, page 5 
paragrapt) [0045]), wherein the expiration date is derived from the date of a calendar 
entry (i.e., Malik discloses a default expiration period 335 for the temporary contact 300 
can be set if the user does not specify an expiration 335. page 5 paragraph [0045]. 
Since an expiration 335 is set by default, a calendar entry must be applied in order to 
determine/derive the expiration date for the temporary contact, and the contact will be 
automatically removed from the user's buddy list after an the expiration date); 
periodically comparing a current date to the expiration date stored for the buddy group 
(i.e., at regular inten/als, check the expiration periods 335, 340 of the temporary group 
310 to ensure that no temporary contacts 300, 320 have expired, page 4 paragraph 
[0042], and page 5 paragraph [0045]); and removing the buddy group, including the 
contact data added to the buddy group, in response to the comparison (i.e., if the 
temporary contact is expired, the temporary contact is removed from the resource list, 
page 4 paragraph [0042] and page 5 paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the combination of the teachings of Knauerhase and 
Keskar to designate the contact as a temporary contact by storing expiration date 
corresponding to the created buddy group, and to remove the contact after expiration 
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date as taught by Malik. One would be motivated to do so to allow the client to control 
how long a contact is stored in the client's buddy list without requiring the client to 
actively monitor and remove old contacts (Malik, page 4 paragraph [0039] lines 14-17). 

Regarding claim 15, Knauerhase teaches the method as described in claim 14. 

the combination of teachings of Knauerhase and Keskar does not explicitly 
teach storing an expiration date corresponding to the created buddy group, wherein the 
expiration date is derived from the date of the selected calendar entry; periodically 
comparing a current date to the expiration date stored for the buddy group; and 
removing the buddy group, including the contact data added to the buddy group, in 
response to the comparison. 

Malik teaches storing an expiration date {expiration period 335, 340, Fig. 3) 
corresponding to the created buddy group {i.e., when expiration date 335 is received, 
ttie temporary contact 300 is recorded into database along witti expiration 335, page 5 
paragraph! [0045]), wherein the expiration date is derived from the date of a calendar 
entry (i.e., Malil< discloses a default expiration period 335 forttie temporary contact 300 
can be set if the user does not specify an expiration 335, page 5 paragraph [0045]. 
Since an expiration 335 is set by default, a calendar entry must be applied in order to 
determine/derive the expiration date for the temporary contact, and the contact will be 
automatically removed from the user's buddy list after an the expiration date)\ 
periodically comparing a current date to the expiration date stored for the buddy group 
(i.e., at regular intervals, check the expiration periods 335, 340 of the temporary group 
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310 to ensure that no temporary contacts 300. 320 have expired, page 4 paragraph 
[0042], and page 5 paragraph [0045]); and removing the buddy group, including tlie 
contact data added to the buddy group, in response to the comparison (i.e., if the 
temporary contact is expired, the temporary contact is removed from the resource iist, 
page 4 paragraph [0042] and page 5 paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the combination of the teachings of Knauerhase and 
Keskar to designate the contact as a temporary contact by storing expiration date 
corresponding to the created buddy group, and to remove the contact after expiration 
date as taught by Malik. One would be motivated to do so to allow the client to control 
how long a contact is stored in the client's buddy list without requiring the client to 
actively monitor and remove old contacts (Malik, page 4 paragraph [0039] lines 14-17). 

Regarding claim 23, this claim comprises the computer program corresponding 
to the method claim 7, same rationale of rejection is applicable. 

11. Claims 8, 16 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Knauerhase et al. (hereinafter, Knauerhase), U.S. Pub. No. 2004/0203746 A1 , in 
view of Roskind, U.S. Pub. No. 2003/0065721 A1. 
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Regarding claim 8, Knauerhase teaches method as described in claim 1 further 
comprising adding the received contact data to a buddy group included with the buddy 
list (i.e., adding the partners to the buddy list of the client, page 2 paragraph [0026]). 

Knauerhase does not teach the buddy group to which the contact data is added 
is detemriined by a predefined policy. 

Roskind teaches a buddy group may be configured without action from the 
instant messaging identity (see abstract). Roskind teaches the buddy group to which 
the contact data is added is determined by a predefined policy (i.e. contacts groups 812 
is created, and screen names are added to the contact groups based on predetermined 
policy such as IM sessions are opened, page 10 paragraphs [0106-0110]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to incorporate the buddy group to which the contact data is added 
is determined by a predefined policy as taught by Roskind in the process of adding 
contacts into the buddy group/list in Knauerhase. One would be motivated to do so to 
allow a buddy group to be automatically created and populated without user action 
(Roskind, page 10 paragraph [0110]). 

Regarding claim 16, Knauerhase teaches method as described in claim 9 further 
comprising adding the received contact data to a buddy group included with the buddy 
list (Le., adding the partners to the buddy list of the client, page 2 paragraph [0026]). 

Knauerhase does not teach the buddy group to which the contact data is added 
is determined by a predefined policy. 
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Roskind teaches a buddy group may be configured without action from the 
instant messaging identity (see abstract). Roskind teaches the buddy group to which 
the contact data is added is determined by a predefined policy (Le. contacts groups 812 
is created, and screen names are added to the contact groups based on predetermined 
policy such as IM sessions are opened, page 10 paragraphs [0106-01 10]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to incorporate the buddy group to which the contact data is added 
is determined by a predefined policy as taught by Roskind in the process of adding 
contacts into the buddy group/list in Knauerliase. One would be motivated to do so to 
allow a buddy group to be automatically created and populated without user action 
(Koskind, page 10 paragraph [0110]), 

Regarding claim 18, this claim comprises the computer program corresponding 
to the method claim 8, same rationale of rejection is applicable. 

12. Claims 26, 28, and 30 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Keskar et al. (hereinafter, Keskar), U.S. Patent No. 6,785,681 B1, in 
view of Malik, U.S. Pub. No. 2003/0220976 Al. 
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Regarding claim 26, Keskar teaches a computer-implemented method of 
managing instant messenger lists (i.e., adding a list of people to a buddy list in an 
instant messaging scenario, col. 5 lines 45-55), said method comprising: 

creating a buddy group within the user's buddy list (i.e., generating/creating a 
list/group of people/buddies who are added to a buddy list, col. 5 lines 31-55), wherein 
the created buddy group (i.e., group of meeting attendees) conresponds to a selected 
calendar entry (i.e., meeting) from an electronic calendar corresponding to the user (I.e., 
meeting attendees can be added to a list of people. If the meeting is to be field online, 
then participants are invited into an instant messaging chat room, col. 5 lines 45-63); 

retrieving, from the selected calendar entry, calendar data (i.e., meeting 
attendees or list of people) that includes participant information for participants of the 
selected calendar entry (i.e., provide a list of people that are relevant to the task, col. 5 
lines 45-55); 

storing the received contact data in the buddy group, wherein the contact data 
received includes the participant information (In instant messaging scenario, the list of 
people/participants can be added/stored to/in a buddy list, col. 5 lines 30-63). 

Keskar does not explicitly teach identifying an expiration date of the buddy 
group, the expiration date derived from the date of the selected calendar entry; 
periodically comparing a current date to the expiration date corresponding to the buddy 
group; and removing the buddy group, including the contact data added to the buddy 
group, in response to the comparison. 
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Malik teaches a system wherein temporary contact aliases are provided (see 
abstract). Malik teaches identifying an expiration date of the buddy group, the expiration 
date is derived from the date of a calendar entry (i.e., Malik discloses a default 
expiration period 335 for the temporary contact 300 can be set/identified if the user does 
not specify an expiration 335, page 5 paragraph [0045]. Since an expiration 335 is set 
by default, a calendar entry must be applied in order to /derive the expiration date for 
the temporary contact, and the contact will be automatically removed from the user's 
buddy list after an the expiration date); periodically comparing a current date to the 
expiration date stored for the buddy group (i.e., at regular intervals, check the expimtion 
periods 335, 340 of the temporary group 310 to ensure that no temporary contacts 300, 
320 have expired, page 4 paragraph [0042], and page 5 paragraph [0045]); and 
removing the buddy group, including the contact data added to the buddy group, in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 4 paragraph [0042] and page 5 
paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Keskar to include the step of identifying 
an expiration date of the buddy group, the expiration date derived from the date of the 
selected calendar entry, periodically comparing a current date to the expiration date 
corresponding to the buddy group, and removing the buddy group, including the contact 
data added to the buddy group, in response to the comparison as taught by Malik. One 
would be motivated to do so to allow the client to control how long a contact is stored in 
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the client's buddy list without requiring the client to actively monitor and remove old 
contacts (Malik, page 4 paragraph [0039] lines 14-17). 

Regarding claim 28, Keskar teaches information handling system (i.e., client 
12a, Fig. 2) comprising 

one or more processor (i.e., CPU 20, Fig. 2); 

a memory accessible by the processors (i.e., memory 24, Fig. 2 col. 1 line 60-col. 
2 line 7); 

a network interface (i.e., interface 38, Fig. 2) connecting the information handling 
system to a computer network (i.e., interface 38 couples the network 16 to client 12a, 
col. 2 lines 10-11); 

a software tool for managing instant messenger lists, the software tool including 
software (i.e., programs 37, Fig. 2 col. 1 line 61 -col. 2 Iine7), the software tool including 
software to; 

creating a buddy group within the user's buddy list (i.e., 
generating/creating a list/group of people/buddies who are added to a buddy list, 
col. 5 lines 31-55), wherein the created buddy group (i.e., group of meeting 
attendees) corresponds to a selected calendar entry (i.e., meeting) from an 
electronic calendar corresponding to the user (i.e., meeting attendees can be 
added to a list of people. If the meeting is to be held online, then participants are 
invited into an instant messaging chat room, col. 5 lines 45-63); 
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retrieving, from the selected calendar entry, calendar data (i.e., meeting 
attendees or list of people) that includes participant information for participants of 
the selected calendar entry (i.e., provide a list of people that are relevant to the 
task, col. 5 lines 45-55); 

storing the received contact data in the buddy group, wherein the contact 
data received includes the participant information (In instant messaging scenario, 
the list of people/participants can be added/stored to/in a buddy list, col. 5 lines 
30-63). 

Keskar does not explicitly teach identifying an expiration date of the buddy 
group, the expiration date derived from the date of the selected calendar entry; 
periodically comparing a current date to the expiration date corresponding to the buddy 
group; and removing the buddy group, including the contact data added to the buddy 
group, in response to the comparison. 

Malik teaches a system wherein temporary contact aliases are provided (see 
abstract). Malik teaches identifying an expiration date of the buddy group, the expiration 
date is derived from the date of a calendar entry (i.e., Malik discloses a default 
expiration period 335 for the temporary contact 300 can be set/identified if the user does 
not specify an expiration 335, page 5 paragraph [0045]. Since an expiration 335 is set 
by default, a calendar entry must be applied in order to /derive the expiration date for . 
the temporary contact, and the contact will be automatically removed from the user's 
buddy list after an the expiration date)] periodically comparing a current date to the 
expiration date stored for the buddy group (i.e., at regular intervals, check the expiration 
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periods 335, 340 of the temporary group 310 to ensure that no temporary contacts 300, 
320 have expired, page 4 paragraph [0042], and page 5 paragraph [0045])\ and 
removing the buddy group, including the contact data added to the buddy group, in 
response to the comparison (i.e., if the temporary contact is expired, the temporary 
contact is removed from the resource list, page 4 paragraph [0042] and page 5 
paragraph [0045]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention was made to modify the teachings of Keskar to include the step of identifying 
an expiration date of the buddy group, the expiration date derived from the date of the 
selected calendar entry, periodically comparing a current date to the expiration date 
corresponding to the buddy group, and removing the buddy group, including the contact 
data added to the buddy group, in response to the comparison as taught by Malik. One 
would be motivated to do so to allow the client to control how long a contact is stored in 
the client's buddy list without requiring the client to actively monitor and remove old 
contacts (Malik, page 4 paragraph [0039] lines 14-17). 

Regarding claim 30, this claim comprises a computer program product stored on 
a computer operable media for performing a corresponding method claim 26, discussed 
above, same rationale of rejection is applicable. 



Conclusion 
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1 3. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

a) Fotsch, U.S. Pub. No. 2005/0083851 A1 discloses database application 
creates a correspondence between a buddy's screen name and one or more phone 
number associated with the buddy. 

b) Haims et al., U.S. Pub. No. 2003/01 05820 A1 . disclose data of databases 
may be used to initiate, manage, and conduct communication sessions among diverse 
participants in an efficient and effective manner. 

c) Tornabene et al., U.S. Pub. No. 2002/0023132 Al discloses a prospective 
member is added to the current members of the group. 

d) Herrero, U.S. Pub. No. 2002/0078007 Al discloses a task management 
program that allows a user to create contact, project, and task records that are stored in 
a database. 

e) Aoki, U.S. Pub. No. 2005/0027805 Al discloses instant messaging and 
enhanced scheduling. 

f) Karstens, U.S. Pub. No. 2005/0071435 Al discloses expiration criteria as 
defined, whereby one or more users of user groups may be considered has having 
expired from consideration by instant messaging function. 

g) Appelman et al., U.S. Pub. No. 2005/01981 72 Al , disclose facilitating 
communications between computer user across a network. 

h) Green et al., U.S. Pub. No. 2004/01 72456 Al , disclose enhanced buddy 
list interface. 
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j) Cahn et al., U.S. 2004/0203381 A1 , disclose an electronic contact group is 
formed for the immediate establishment of the network or saved for later use. 

i) Donnelly et al., U.S. Patent No. 6,049,776, disclose a resource 
management system including a server having a database containing files storing 
information on employees, and employee schedules. 

14. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Oanh Duong whose telephone number is (571) 272- 
3983. The examiner can normally be reached on Monday- Friday, 9:30AM - 6:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Saleh Najjar can be reached on (571) 272-4006. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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